Method and apparatus for detecting and handling evil twin access points

ABSTRACT

Methods and apparatus for detecting and handling evil twin access points (APs). The method and apparatus employ trusted beacons including security tokens that are broadcast by trusted APs. An Evil twin AP masquerades as a trusted AP by broadcasting beacons having the same SSID as the trusted AP, as well as other header field and information elements IE in the beacon frame body containing identical information. A sniffer on the trusted AP or in another AP that is part of a Trusted Wireless Environment (TWE) receives the beacons broadcasts by other APs in the TWE including potential evil twin APs. The content in the header and one or more IEs in received beacons are examined to determine whether a beacon is being broadcast by an evil twin. Detection of the evil twin are made by one of more of differences in MAC addresses of trusted and untrusted beacons, time jitter measurements and replay detection using timestamps in the beacons, detection of missing security tokens in untrusted beacons and detection that a security token that is mimicked by an evil twin is invalid. In one aspect, the security token is stored in a vendor-specific IE in trusted beacons that is generated by employing a secret key using a cryptographic operation operating on data in the beacon prior to the vendor-specific IE.

CLAIM OF PRIORITY

The present application is a continuation of U.S. patent applicationSer. No. 16/866,477, entitled “METHOD AND APPARATUS FOR DETECTING ANDHANDLING EVIL TWIN ACCESS POINTS,” filed May 4, 2020, for which thebenefit of the priority date is claimed under 35 U.S.C. § 120 and forwhich the entirety is incorporated by reference herein.

FIELD OF THE INVENTION

The field of invention relates generally to securing data networks and,more specifically but not exclusively relates to detecting evil twinaccess points (APs) in a protected Wireless Environment and othermethods to create a Trusted Wireless Environment (TWE).

BACKGROUND INFORMATION

The use of wireless communication in today's environments is ubiquitous.It seems that everyone has at least one “smart” wireless device, such asa smart phone or tablet, and many have other types of mobile computingdevices, such as laptops, notebooks, Chromebooks, etc., that supportwireless communication. In addition to cellular and mobile computing,wireless communication technologies are used for other purposes, such asaudio systems, portable telephone systems, screen casting, andpeer-to-peer communication to name a few.

The most common wireless technologies include Wireless Wide AreaNetworks (WWAN) (e.g., LTE, HSPA+, UMTS, GPRS, generally associated withcellular networks), Wireless Local Area Networks (WLAN), includingInstitute of Electrical and Electronics Engineers (IEEE) 802.11a,802.11b, 802.11g, 802.11n, 802.11ac standards (commonly referred to asWi-Fi™ WLANs) and Wireless Personal Area Networks (WPAN), such asBluetooth™. The focus of this disclosure is 802.11-based Wi-Fi™ WLANsand associated equipment. For convenience, these may be referred toherein as 802.11 networks, Wi-Fi™ networks, 802.11 Access Points (APs),Wi-Fi™ APs, etc.

Public Wi-Fi™ networks are widespread, such as in coffee shops, cafes,stores, airports, subways, as well as public offices and companies. Eachconnection to a Wi-Fi™ networks is made via an AP, commonly referred toas “hotspots” or “Wi-Fi™ hotspots”. A wireless access point may be awireless router, another computer connected to the network, or anydevice that allows a computer to connect to the network. The network maybe the Internet, a local area network (LAN), a wide area network (WAN),home network, corporate intranet, ad hoc network or any computernetwork. The wireless AP broadcasts a service set identifier (SSID)identifying the presence of a wireless network. From a user viewpoint,the SSID is the name associated with the wireless network.

As the number of wireless access points has increased, cybercriminalshave developed methods to intercept information destined for thesewireless APs. One such threat to the security of a wireless access pointis known as the “evil twin” access point. The cybercriminal deploys awireless AP that broadcasts the same SSID as a known wireless accesspoint, often with stronger signal strength. For convenience, mobiledevices are commonly set up (by users) to automatically reconnect toknown networks identified by their SSIDs, e.g., an SSID with the samename as a previously connected to SSID. Mobile devices are alsotypically set to connect to a known SSID broadcasting the strongestsignal. Because the evil twin access point is broadcasting the same SSIDas a known wireless access point and (oftentimes) at a stronger signalstrength, the mobile device may automatically connect to the evil twinAP instead of the legitimate wireless AP. Evil twin APs may also mimicthe MAC (Media Access Channel) address of the legitimate AP.

Although Wi-Fi™ networks have long supported security mechanisms,including WPA (Wi-Fi Protected Access), WPA2 and (just recently) WPA3,such measures are inconvenient for users and are often not used forpublic Wi-Fi™ networks. For example, if a security mechanism such as WPAor the like is used at a coffee shop, store, airport, etc., the userwill need to obtain the password to access the network. Therefore, manyWi-Fi™ APs are used without security.

Under WPA and WPA2, once connected, communications between the Wi-Fi™APs and the user mobile device are encrypted. Conversely, suchcommunications on non-secure Wi-Fi™ networks are “in the clear,” meaningthey are not encrypted. Accordingly, once the mobile device is connectedto an evil twin AP of a non-secure legitimate AP, the cybercriminal hasaccess to information contained in communications originally intendedfor the legitimate AP. This information may include credit cardinformation, usernames and passwords, and other sensitive information.The cybercriminal can also use the evil twin AP to infect the mobiledevices such as notebooks and laptops with a computer virus or othermalware. Because the evil twin AP broadcasts the same SSID as thelegitimate AP (as well as other beacon matching information), the useris unaware he or she has connected to the evil twin wireless accesspoint and that communications are being accessed by the cybercriminal.

Evil twins may also be set up to establish “man-in-the-middle” (MitM)positions, and extract sensitive information, often without leaving anytraces behind. For example, the evil twin AP may supply Internet servicethrough 4G LTE connections (rather than a wired network connection) toevade network security. Once in a MitM position, the attacker hascomplete control over the Wi-Fi™ session. These cybercriminals canleverage well-known tools to duplicate popular login forms for socialsites or email hosting platforms, intercept the credentials in plaintext, forward them to the real websites, and log in the user. As thetarget, the users believe they have simply logged in to their emailaccounts, while in reality the users have handed over their credentialsto an attacker.

Many APs are configured to use WPA2-Personal, which requires a passwordor passphrase to connect to the AP. An evil twin AP may masquerade as asecure AP and query the user/user device for a password or passphrasewhile accepting anything entered by the user. As with an evil twin foran unsecure AP, the user is unaware he or she is connected to the eviltwin. In addition, once armed with the password/passcode for thelegitimate secure AP, an operator of the evil twin may connect to thatsecure AP and use communication facilities provided by the secure AP.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified:

FIG. 1 is a schematic diagram of a trusted wireless environment (TWE)including a mix of trusted and untrusted access points to which one ormore clients are coupled;

FIG. 1 a is a schematic diagram illustrating further details of the TWEof FIG. 1 relating to provisioning security data;

FIG. 2 is a diagram illustrating the format of an IEEE 802.11 beaconframe including a vendor-specific element containing a nonce and asecure token;

FIG. 2 a is a diagram illustrating the format of a generic IEEE 802.11management frame including a vendor-specific element containing a nonceand a secure token;

FIG. 3 a is a diagram illustrating the format of a trusted beacon frame,according to a first embodiment;

FIG. 3 b is a diagram illustrating the format of a trusted beacon frame,according to a second embodiment;

FIG. 3 c is a diagram illustrating the format of a trusted beacon frame,according to a third embodiment;

FIG. 4 is a diagram of an HMAC algorithm;

FIG. 5 is a diagram illustrating operations and logic implemented by an“sniffer” to detect evil twin APs, according to one embodiment;

FIG. 5 a is a diagram illustrating further operations and logic fordetecting an evil twin AP, according to one embodiment;

FIG. 6 is a flowchart illustrating operations and logic for validating asecurity token in a received beacon, according to one embodiment;

FIG. 7 is a diagram illustrating determination of authenticity for asecurity token employing a MAC or HMAC;

FIG. 8 a is a diagram illustrating the format of a trusted proberesponse, according to a first embodiment;

FIG. 8 b is a diagram illustrating the format of a trusted proberesponse, according to a second embodiment;

FIG. 8 c is a diagram illustrating the format of a trusted proberesponse, according to a third embodiment;

FIG. 9 a is a message flow diagram illustrating examples of trustedbeaconing and use of trusted probe responses with and without trustedendpoint agents (TEPA);

FIG. 9 b is a message flow diagram illustrating examples of neighborbeaconing, rogue beaconing, and evil twin beaconing;

FIG. 10 is a process flow diagram illustrating generation of a trustedbeacon, according to one embodiment;

FIG. 11 is a process flow diagram illustrating generation of a trustedprobe request, according to one embodiment;

FIG. 12 is a process flow diagram illustrating generation of a trustedprobe response, according to one embodiment;

FIG. 13 is a message flow diagram illustrating aspects of cloud-basedprovision of security data, according to one embodiment;

FIG. 14 is a message flow and logic diagram illustrating a trustedassociation sequence initiated by a trusted probe request, according toone embodiment;

FIG. 15 is a message flow diagram illustrating use of a trusteddeauthentication;

FIG. 16 is a block diagram illustrating example components of arepresentative wireless device configured to implement aspects of thefunctionality disclosed herein, in accordance with some embodiments; and

FIG. 17 depicts a block diagram illustrating example components of arepresentative mobile device that may be implemented as a protectedclient, in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments of methods and apparatus for detecting and handling eviltwin access points are described herein. In the following description,numerous specific details are set forth to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that the invention can bepracticed without one or more of the specific details, or with othermethods, components, materials, etc. In other instances, well-knownstructures, materials, or operations are not shown or described indetail to avoid obscuring aspects of the invention.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” invarious places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments.

For clarity, individual components in the Figures herein may also bereferred to by their labels in the Figures, rather than by a particularreference number. Additionally, reference numbers referring to aparticular type of component (as opposed to a particular component) maybe shown with a reference number followed by “(typ)” meaning “typical.”It will be understood that the configuration of these components will betypical of similar components that may exist but are not shown in thedrawing Figures for simplicity and clarity or otherwise similarcomponents that are not labeled with separate reference numbers.Conversely, “(typ)” is not to be construed as meaning the component,element, etc. is typically used for its disclosed function, implement,purpose, etc.

Definitions

-   -   802.11 family of specifications: Specifications and/or standards        published by the IEEE under IEEE 802.11 (WIRELESS LOCAL AREA        NETWORKS).    -   Client: Any endpoint device on a network. Examples include        computers, mobile devices, and IoT devices. Clients are also        known as stations.    -   Endpoint: synonym for Client or Station    -   Access Points (AP): An AP configured to operate in accordance        with an 802.11 specification/standard.    -   Node: A generalized term for any device in the network. In a        wireless network this may include but is not limited to an AP        and a Client.    -   RF Space: The three-dimensional space where two or more wireless        devices may detect communications from one to the other device        with sufficient signal strength to allow digital communications.        Any two nodes may create a non-congruent RF Space that may or        may not form a partial union with another space.    -   HMAC (Hash-based Message Authentication Code)    -   Hash Function: Any function that can be used to map data of        arbitrary size to fixed-size values.    -   Cryptograph Hash Function: A hash function that is suitable for        use in cryptography. A mathematical algorithm that maps data of        arbitrary size to a bit string of a fixed size and is a one-way        function.    -   Beacon: A beacon refers to beacon as defined in the 802.11        family of specifications or other communications protocol.    -   Trusted Beacon: A beacon that includes security information    -   Probe Request: An IEEE 802.11 Endpoint Request for a Probe        Response. A Probe Request may contain much of the same        information as a Beacon.    -   Trusted Probe Request: A Trusted Probe Request adds security        information as defined herein.    -   Probe Response: An IEEE 802.11 response to a Probe Request.    -   Trusted Probe Response: A Probe Response to a Trusted Probe        Request    -   Rogue AP: An AP that is connected to a protected network that        does not support transmitting a Trusted Beacon.    -   Neighbor AP: An AP that shares at least some RF space with a        protected network, yet the neighbor is not part of the protected        network and does not share the same SSID as the protected        network.

Protected Networks

-   -   Deauthentication Frame: A Station or AP can send a        Deauthentication Frame when all communications are terminated        (when disassociated, still a station may still be authenticated        to the cell). Deauthentication Frame may be referred to as        deAuth or Deauth frames herein.    -   Deauthentication Attack: DeAuth Attacks are cyber-attacks to        force a client to re-associate, that may, for example, make the        client vulnerable to associating with an Evil Twin.    -   Disassociation Frame: Once a station associated to an AP, either        side can terminate the association at any time by sending a        disassociation frame. It has the same frame format as        deauthentication frame. A station can send a disassociation        frame causing it to leave the current cell and roam to another        cell. An AP could send disassociation frame causing the station        try to use invalid parameters.    -   MitM Attack: In cryptography and computer security, a        man-in-the-middle attack (MITM) is an attack where the attacker        secretly relays and possibly alters the communications between        two parties who believe that they are directly communicating        with each other.    -   Protected Wireless Networks: A Wireless network that places        Tokens in some packets and scans for them.

Trusted Endpoint Agent—TEPA

-   -   A Trusted Endpoint Agent (TEPA) is a program running on a client        device such as a PC, smart phone, printer, IoT device, to        monitor and assure secure communications with access points or        other network devices. A TEPA may be combined with other        programs, such as Endpoint Agents or otherwise built into the        device such as in the operating system, drivers or endpoint        hardware or a combination there of.    -   Sniffing: Listening for and/or decoding management frames and        communication packets. Sniffing devices may be independent        devices or may be combined within other network module(s). For        example, an AP may use its 802.11 radio to sniff or may have an        additional 802.11 radio dedicated to sniffing.    -   Security Remediation: Security remediation is an action in        response to a detected intrusion, such the detection of an evil        twin. The step or steps taken when a security issue is detected        include, but are not limited to logging the event, alerting        users and/or administrators, transmitting deauth packets,        sandboxing users and/or APs, and/or terminating wireless access        of clients, APs routers, servers and or the entire network.    -   Wireless Environment: Within common RF ranges to be able to        communicate between at least two wireless devices at least        unidirectionally.    -   Protected, Trusted, and Authorized APs: APs that are capable of        transmitting a valid Token.    -   Evil Client: An unauthorized client that issues a Probe Request        to a protected SSID that lacks a valid Token in the probe        request. Malicious uses of Evil Clients include Denial of        Service Attacks, and Oracle Attacks against WiFi pass phrases.    -   Evil Twin AP: Evil Twins are Access Points in the same RF        environment as a protected network that impersonate an        authorized AP with one or more of the following characteristics:        -   Transmits the same SSID as the protected devices        -   Transmits the same MAC address (BSSID) as a protected AP    -   Evil Node: The generalized case if either as Evil Twin AP or        Evil Twin Endpoint.    -   Security Appliance: A device in a network that is able to        provide security services to a network. Non-limiting examples of        Security Appliances include firewalls and the like.    -   Keys: Keys, in this application, refers to cryptographic keys        that are shared between two or more nodes to facilitate secure        communication between these nodes. The system may have more than        one set of keys. Keys may be pre-shared, exchanged though public        keys, a public key infrastructure, certificates or other means.        Keys may be symmetric or asymmetric.    -   Wireless Network: two or more nodes (i.e., wireless-enabled        devices) that communicate wirelessly using RF signals that are        transmitted over a shared wireless media.

FIG. 1 shows a trusted wireless environment (TWE) 100 including aplurality of access points to which one or more client devices (referredto as clients for simplicity) are coupled. The APs include threeauthorized APs 102, 104, and 106, each having the configuration shownfor authorized AP 104. Authorized APs are also referred to as protectedAPs and trusted APs. TWE 100 further includes a neighbor AP 108, an eviltwin AP 110, and a rogue AP 112. The wireless clients include protectedclients 114, 116, 118, 120, and 122, mobile phone clients 123, 124, and126, and an Internet of Things (IoT) device 128.

Generally, TWE 100 is illustrative of a private environment, a publicenvironment, or a mixed private/public environment that includes one ormore trusted APs and/or sniffers described herein. Each of the APsillustrated in FIG. 1 is an IEEE 802.11 access point employing one ormore of IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac standardsand/or future 802.11 or Wi-Fi™ standards. Each AP will have a respectivecoverage area that is generally a function of the particular 802.11 PHY(Physical Layer) protocol, transmitter broadcast strength and radiosignal propagation characteristics of the environment. For example,different APs may be in separate rooms or buildings, on differentfloors, etc. Generally, the radio signals broadcast from the various APsmay overlap, enabling a given AP to detect radio signals broadcast byone or more other APs in the RF space, and enabling clients at givenlocations to connect to one or more APs.

Security Facilities

Each authorized AP 102, 104, and 106 include an agent 136, a securityservice 138, and a scanning+WIPS (Wireless Intrusion Prevention System)module 140. Each agent 136 is linked in communication with a UnifiedThreat Management (UTM) firewall 130 via a respective link, as depictedby links 142, 144, and 146. In one embodiment, UTM firewall 130 includesa built-in router or switch 148 and links 142, 144, and 146 are Ethernetlinks. In one embodiment, agents 136 communicate with UTM firewall 130using a secure protocol over TCP/IP, such as SSL (Secure Sockets Layer)and/or HTTPS. UTM firewall also provides access to external networkresources (e.g., Web pages, Web services, data centers, etc.) accessedvia one or more networks including the Internet 150. As further shown inFIG. 1 , UTM firewall 130 is linked in communication with UTM cloudcontroller 132 via a VPN link 152.

As described and illustrated in further detail below, authorized APs102, 104, and 106 are operated in a coordinated manner using adistributed set of security components including agents 136, securityservices 138, and scanning+WIPS modules 140. In addition to thesesecurity components, security aspects may be implemented in clients,such as implemented by trusted end-point agents (TEPA) 154 for protectedclients 114, 116, 118, 120, and 122.

In addition to other security functions/operations, the distributedsecurity components provide prevention and/or detection andnotification, as depicted by the prevention icons 156 and thedetection/notification icons 158. Prevention means clients are preventedfrom establishing connections with certain APs and prevented fromestablishing ad-hoc networks. Detection and notification comprisedetecting certain types of APs and clients, as well as detectingattempts by clients to connect to unauthorized APs and providingcorresponding notifications to application security components in thesystem. For example, detection and notification may include one or moreof logging detected events, providing notification of detected events(e.g., alerts) to UTM cloud controller 132 and/or push notifications toregistered management and/or operator devices, as well as other types ofnotifications.

Unauthorized APs include neighbor APs, evil twin APs, and rogue APs.Generally, a neighbor AP is an AP in a wireless environment that has acoverage area that overlaps with the coverage area of one or moreauthorized APs but is operated in a normal, non-malicious manner.Examples of neighbor APs include APs hosting public hotspots, such as anAP at a STARBUCKS™ coffee shop. An otherwise authorized AP with amisconfigured pre-shared key (PSK) is handled in a similar manner to aneighbor AP described and illustrated herein.

A rogue AP is an AP that has been coupled to a network to which one ormore authorized APs are coupled, but is not configured to operate (or isnot operated) as an authorized AP. For example, an employee located inan office with a weak wireless connection might chose to bring in his orher own AP and connect it to the company's Ethernet LAN or WAN (i.e.,corporate network). For performance and security reasons (among others),most enterprise companies have wired networks to which various computersare connected, such as desktops, workstations, and servers. It is commonto have an Ethernet (RJ45) jack in the wall of each office or cubicle,and/or otherwise there are multiple Ethernet jacks scattered throughoutthe enterprise office space. Without security measures, an employee cansimply connect an AP to the corporate network via an Ethernet cable.Even when some types of security measures are in place, an employee mayconfigure an AP to appear on the corporate network as a client end-pointdevice that has been authenticated. Also, a personal computer, laptop,notebook, etc. may be set up to act as an AP.

Evil twin APs are discussed above. Generally, an evil twin AP will bedeployed in a public location, although there are instances in whichevil twin APs are deployed in corporate environments. In addition, anevil twin AP may be deployed in a private location that is near acorporate environment such that the evil twin AP is accessible to userdevices within the corporate environment (with appropriate antennasand/or signal amplification evil twins may be located at a substantialdistance from a corporate or private location).

In some instances, an unauthorized wired client such as a laptop,notebook, or desktop computer will attempt to connect to an Ethernetnetwork to which UTM firewall 130 is connected. As depicted by anunauthorized wired 134, the attempted connection is both detected andestablishment of a connection to the Ethernet network is prevented.

FIG. 1 a shows further aspects relating to provisioning ofsecurity-related data. UMT cloud controller maintains a database 158 inwhich various security information is stored, as depicted by a protectedclient list, a list of APs connected to the network (e.g., rogue APs),whitelisted APs, a group secret, a list or protected SSIDs and AP RSAkey pair. The protected client list is a list of protected clients(e.g., clients that are protected using security measures associatedwith and/or managed by UTM cloud controller 132 and UTM firewall 130).Whitelisted APs are APs that are trusted APs, which may generallyinclude authorized APs. A group secret is a secret that is distributedto the authorized APs and may take various forms including a key.Protected SSIDs is a list of SSIDs that are used by APs that areprotected, such as authorized APs. AP RSA key pairs are pairs of RSA(Revest-Shamir-Adleman) keys that are used by the authorized APs, whichinclude a public encryption key and a private (secret) decryption key.As an option, other cryptographic key systems may be used.

UMT cloud controller 132 pushes down client TEPA configuration data 160to the TEPA 154 for protected clients 114, 116, 118, 120, and 122, whichincludes EPA (end-point agent) certificates, network keys, and theprotected SSID list. UMT cloud controller 132 also pushes down securitydata 162 to UTM firewall 130 including UTM Firewall certificates and acertificate revocation list. UMT firewall 130 pushes down authorized APconfiguration data 164 to each of authorized APs 102, 104 and 106including a protected client list, a rogue AP list, the whitelisted APlist, a rogue client list, the list of protected SSIDs, and the groupsecret. The AP configuration data 162 may also include an AP certificateand a certificate revocation list. UMT firewall 130 also acquiresvarious information about AP and clients in TWE 100 and pushescorresponding system information 166 to UTM controller 132 including alist of authenticated clients, a list of rogue clients, system alerts,visibility data, and devices attached to the network.

Returning to FIG. 1 , the instances of TEPA 154 on protected clients114, 116, 118, 120, and 122 enables these clients to establish securecommunication sessions with authorized access points 102, 104, and 106.TEPA 154 may also prevent a protected client from establishing acommunication session with an unauthorized AP while connected

Detection of Evil Twins Using Trusted Beacons

IEEE 802.11 APs periodically transmit a management frame called a beaconframe or simply “beacon” for short. 802.11 beacons contain informationabout the network including capabilities and configuration information,serve to announce the presence of a wireless LAN and are used tosynchronize the members of a service set.

FIG. 2 shows the basic structure of an 802.11 beacon frame 200. Thenumber shown above most elements is the number of Octets used by theelement, where an Octet is 8-bits in length (1 Byte) (noting eachelement is also identified by a numerical value). Beacon frame 200includes a 28-Octet header 202, a frame body 204 having a length of0-2320 Octets, and a 4-Octet FCS (frame check sequence) 206. Frame body204 has three fixed parameters including a 16-bit timestamp 208, 16-bitbeacon interval 210, and a 16-bit capability information field 212. Thefixed parameters are followed by tagged parameters 214 comprisingmultiple information elements (IEs) having variable lengths, somemandatory and some optional.

Required tagged parameters 214 shown for beacon frame 200 include anSSID IE 216 (commonly referred to as the SSID), and a supported rates IE218. Also shown are multiple mandatory and optional IEs 220 havingvariable lengths, followed by an optional vendor-specific IE 222.Vendor-specific IE 222 includes an 8-bit tag number 226, an 8-bit length226, a 24-bit organization unique identifier (OUI) 228, an 8-bitvendor-specific type 230, and a data element 232 have a length from0-252 Bytes.

Under one embodiment for detecting the presence of an evil twin AP,authorized APs transmit “trusted” beacons including an encrypted“secure” token that employs a hash over a concatenation of data inselected beacon elements or over the whole beacon except for thevendor-specific IE. The beacon header fields and body frame IEs that arehashed are collectively referred to as BeaconS, and the secure token isreferred to as TokenBS. As shown in FIG. 2 , in one embodiment dataelement 232 in vendor-specific IE 222 includes a combination of a nonce234 and a TokenBS 236 that are used by the trusted beacon.

FIGS. 3 a, 3 b, and 3 c show respective embodiments of trusted beacons300 a, 300 b, and 300 c. For illustrative purposes, only selected IEs ofthe trusted beacons are shown; it will be recognized that the actualtrusted beacons would include additional IEs that are not shown forclarity.

As shown in FIG. 3 a , trusted beacon 300 a includes a set of signedfields referred to as BeaconS 302 and a token 304. BeaconS 302 includesthe beacon header 306 and the beacon body frame 308, the latter of whichincludes all or selected IEs 310 and a vendor-specific element 222 orall IEs. Generally, the trusted beacon will include any required IEs,applicable optional IEs (including vendor-specific element 222) andpotentially other optional IEs. As shown in for fourth and fifth rows ofFIG. 3 a the header fields include the MAC address 312 (called theBSSID), and the IEs include a timestamp 208, beacon interval 210,capability 212, SSID 216, and a Traffic indication map (TIM) 314. Theellipses ‘ . . . ’ reference other IEs. Depending on the IEEE802.11-based PHY and other settings, various additional required IEswill be present in the trusted beacons. Optional IEs for a givenimplementation may also be present.

Following these required and optional IEs is vendor-specific IE 222having a data element 232 used for a nonce 234 and a TokenBS 236 a. Inthis embodiment,TokenBS=Enc(Nonce∥H(BeaconS),K),where the BeaconS fields/content is hashed using a hash function H,concatenated with the (preceding) Nonce, and then encoded using key K.In some embodiments the hash function is a cryptographic hash functionsuch as MD5, SHA-1, SHA-2, SHA-3, BLAKE2, BLAKE3, etc. although moregenerally any hash function may be used, such as a simple hash.

Under the embodiments of trusted beacons 300 b and 300 c in FIGS. 3 band 3 c , an HMAC is used for TokenBS 236 b and 236 c:TokenBS=HMAC(BeaconS,K)where K is the HMAC key and the HMAC message m used for TokenBS 236 bincludes BeaconS while the HMAC message m used for TokenBS 236 cincludes the concatenation of nonce 234 and BeaconS.

The use of secure tokens implemented in trusted beacons 300 a, 300 b,and 300 c can be applied to other types of management frames, includingbut not limited to probe requests, probe responses, authenticationframes, and associated frames (requests and responses). For example,FIG. 2 a shows a generic management frame format 200 a. Since a beaconframe is a type of management frame, the header 202, frame body 204, andFCS 206 are the same as shown in FIG. 2 . Frame body 204 will begin withone or more mandatory IEs, as depicted by required IEs 217 and 219,followed by multiple IEs 221 with variable lengths, some mandatory, someoptional, where the mandatory IEs are dependent on the particular typeof management frame and other settings. IEs 221 will be followed byvendor-specific IE 222, which is the last IE for most management frames,with an exception being probe responses, as illustrated below in FIGS. 8a, 8 b , and 8 c.

As shown in the lower left of FIG. 2 a , the following generalized tokenformulas are defined:TokenS=Enc(Nonce∥H(DataS)),K)TokenS=HMAC(DataS),K)TokenS=HMAC(DataS∥Nonce),K)In cryptographic hashes such as MD5, SHA-1, etc., the data to be hashedis referred to as “data”; in FIG. 2 a this data is DataS 238, which maygenerally comprise a concatenation of data in multiple fields, or in thecase of management frames, data in multiple IEs. As shown by DataS 238,in some embodiments the message m data will include all of themanagement frame content prior to vendor-specific IE 222. Optionally,selected IEs among all the IEs may be used. The token that is calculatedwill be included in a TokenS field 237 of data field 232. In thisexample, the TokenS follows a nonce 234. Alternatively, a nonce is notused, and the token occupies all of data field 232 for vendor-specificIE 222.

The HMAC algorithm is defined in RFC 2104. HMAC uses a cryptographichash function ‘H’ and a secret key ‘K’. An iterative cryptographic hashfunction such as MD5 or SHA-1 may be used to calculate the HMAC. WhenMD5 or SHA-1 are used, the resulting MAC algorithm is called HMAC-MD5 orHMAC-SHA-1, for instance; however, the embodiments are not limited toHMAC-MD5 or HMAC-SHA-1, but rather may use any cryptographic hashfunction suitable for use in an HMAC algorithm. The cryptographicstrength of the underlying hash function, along with the size andquality of the key and the size of the hash output length in bits,define the cryptographic strength of the HMAC.

The HMAC function definition is,

$\begin{matrix}\left. {{{HMAC}\left( {K,m} \right)} = {H\left( {\left( {K^{\prime} \oplus {opad}} \right){{H\left( \left( {K^{\prime} \oplus {ipad}} \right) \right.}}m} \right)}} \right) \\{K^{\prime} = \left\{ \begin{matrix}{H(K)} & {K{is}{larger}{than}{block}{size}} \\K & {otherwise}\end{matrix} \right.}\end{matrix}$where:

-   -   H=Cryptographic hash function    -   m=Message to be authenticated    -   K=Secret key padded with extra 0's (ipad/opad) to the block size        of the hash function.    -   K′ is a block-sized key derived from the secret key    -   ∥ denotes concatenation    -   ⊕ denotes bitwise exclusive or (XOR)    -   opad is the block-sized outer padding, consisting of repeated        bytes valued 0x5c    -   ipad is the block-sized inner padding, consisting of repeated        bytes valued 0x36

FIG. 4 shows a graphical representation of the HMAC algorithm. HMACblock 402 includes the secret key K and message m. Key K and the ipadare provided as inputs to an XOR block 404, which outputs the XOR result(1 or 0) to a summation block 406. Message m is also feed into summationblock 406. The output of summation block 406 is provided as an input tohash function H. Key K and the opad are provided as inputs to an XORblock 408, which output the XOR result (1 or 0) to a summation block410. The second input to summation block 410 is an output from hashfunction ‘H’. Hash function ‘H’ also produces an output 412.

FIG. 5 shows a diagram 500 illustrating operations and logic implementedby an “sniffer” to detect evil twin APs, according to one embodiment.Generally, a sniffer may be implemented in a stand-alone network elementor an existing network element such as an authorized AP. In oneembodiment sniffers are implemented in scanning+WIPS modules 140 inFIGS. 1 and 1 a.

As shown in a block 502, authorized AP(s) broadcast beacons withsecurity tokens on a periodic and repeated basis (e.g., as defined bythe beacon interval IE). Concurrently, an evil twin AP periodicallybroadcasts beacons without security tokens or without a valid securitytoken. As discussed above, an evil twin AP will attempt to mimic alegitimate AP (in this case an authorized AP)—the level of mimicking mayvary, from a minimum level under which the SSID of a legitimate AP ismimicked, to a more advanced level under which an evil twin AP willmimic additional aspects, such as the MAC (BSSID) address of thelegitimate AP. Some evil twins APs may mimic the beacons of a legitimateAP, under which case the entire beacon content will be copied. This willresult in the evil twin AP broadcasting a beacon with a security token,but that token and/or the beacon will be invalid, as described below.

If a neighbor AP is present, the neighbor AP will also periodicallybroadcast beacons without security tokens, as shown in a block 506.

As shown in a block 508, the sniffer “listens” for AP beacons and parsesthe beacon IEs to extract their values. In this example, the snifferwill be listening for beacons transmitted by one or more authorized APs,an evil twin AP, and a neighbor AP. In a decision block 510, the snifferdetermines whether the SSID is in its protected list. For example, theprotected list may contain a list of authorized APs. A neighbor AP willhave an SSID that is not in the protected list, and thus the answer todecision block 510 will be NO and the logic will proceed to a block 512in which the neighbor AP is identified as a neighbor AP.

At the least, an evil twin AP will mimic the SSID for the AP it ismasquerading to be. In this example, the evil twin AP will mimic theSSID for an authorized AP. For example, evil twin AP 110 in FIG. 1 maymasquerade as authorized AP 104. In this case, the SSID for the eviltwin will be in the protected list, and the logic will proceed to adecision block 514 where a determination is made to whether the beacon(transmitted by the evil twin AP) includes a valid token. This mayinclude determining whether there is a token present, as well asdetermining a token that is present is invalid. If the token isdetermined to be valid, then the AP broadcasting the beacon is a trustedAP, as shown in a block 516. Conversely, if the token is missing or isotherwise determined to be invalid, the beacon is being transmitted byan evil twin AP. Accordingly, the answer to decision block 514 and NO,and the logic proceeds to a block 518 that identifies the AP as an eviltwin AP and one or more remediation actions are taken. In this example,the one or more remediation actions include sending (via broadcasts)Deauthentication frames (Deauths) to any authenticated clients that arewithin the broadcast range of the sniffer or a proxy for a sniffer, asdepicted in a block 520. For example, a sniffer that is implemented in astand-alone network element and/or type of element that is not capableof transmitting Deauths may use an authorized AP to transmit theDeauths. In some embodiments in which sniffer functionality isimplemented in a trusted AP the trusted AP includes multiple 802.11radios, with one of the radios being used by the sniffer.

FIG. 5 a shows a diagram 500 a illustrating further operations and logicfor identifying evil twin APs. Continuating with a YES determination fordecision block 510 that the SSID is in the protected list, adetermination is made in a decision block 522 whether the MAC address(BSSID) is in a whitelist, or optionally, whether the MAC address is ina protected list separate from the whitelist. In one embodiment, thewhitelist will contain a list of trusted APs with their MAC addressesand SSIDs. If the MAC address is not in the whitelist and/or protectedlist, the AP transmitting the beacon is identified as an evil twin, asdepicted by a NO answer to decision block 522 proceeding to block 518.In one embodiment, using a MAC check may be performed with aconventional beacon (frame) that does not include a security token. Inother embodiments, the beacon will include a security token.

If the MAC address is in the whitelist or protected list (asapplicable), the answer to decision block 522 is YES and the logicproceeds to a decision block 524 to determine whether the beaconincludes a security token. If not, the answer to decision block 524 isNO and the logic proceeds to identify the AP transmitting the beacon asan evil twin AP in block 518.

If the beacon includes a security token (or some data in thevendor-specific IE), the answer to decision block 524 is YES, and thelogic proceeds to a decision block 526 to determine whether a timejitter event is observed. In one embodiment, time jitter may bedetermined by a difference between the time at the sniffer and thetimestamp in the beacon. For example, each AP will include a clock thatgenerates timestamps that are used for each beacon that is transmitted,with a unique timestamp being included in each beacon. In oneembodiment, the sniffer will be either implemented in an authorized APor communicate with an authorized AP to synchronize its clock with theauthorized AP. In some embodiments, all authorized APs (when multipleauthorized APs are operating in a shared wireless environment) willsynchronize their clocks. In some embodiments the clock synchronizationmay be out-of-band (e.g., using communications between the APs over anEthernet LAN or WAN to which each of the authorized APs are connected)using the Network Time Protocol (NTP) or similar protocol, or be in-bandusing the timestamp and other timing information contained in beacons.

Timestamp field 208 has a length of 8 Octets (64-bits) and the timestampvalues may be used for various timing purposes, such as use with timingfor MIMO signals, and thus may be very precise (e.g., times are providedin nanosecond increments). If an evil twin AP is mimicking beacon framesbeing broadcast by an authorized AP, the timestamp will differ from whenthe authorized AP actually transmitted the beacon, and when thisdifference in time is greater than some threshold ‘T’, a time jitterevent will be indicated and the answer to decision block 526 will beYES, causing the logic to proceed to identify the AP transmitting thebeacon as an evil twin AP.

Depending on the 802.11 PHY, a beacon may include time offsetinformation to enable an evil twin to synchronize its time with anauthorized AP and if the evil twin mimics all IEs in beacons transmittedby an authorized AP while substituting its own timestamp, time jittermay not be detected in decision block 526. Accordingly, the answer todecision block 526 is NO and the logic proceeds to a decision block 528in which a determination to whether a recent replay is detected. Forexample, if the evil twin repeats transmission of the same beacon, thetimestamp value for sequential beacons will be the same. This is anindication of a replay event, since each beacon should have its ownunique timestamp. The timestamps should monotonically increase with eachsubsequent beacon transmission, which may be detected by storing thetimestamp for a last (previous) beacon and a new beacon.

If a replay event is detected, the answer to decision block 528 is YESand the logic proceeds to identify the AP transmitting the beacon as anevil twin AP in block 518. If the answer to decision block 528 is NO orif the alternate YES path 529 to decision block 524 is taken, the logicproceeds to determine whether there is a hash match in a decision block530.

FIG. 6 shows a flowchart 600 illustration operations and logic fordetecting a hash match, according to one embodiment. The process beginsin a start block 602 in which the beacon is received (BeaconR). In ablock 604, TokenBS is decrypted from BeaconR. From above, TokenBS 236 ais derived from,TokenBS=Enc(Nonce∥H(BeaconS),K).An authorized AP has a copy of K, the secret key shared by theauthorized APs and authorized clients. Accordingly, key K is used todecrypt Cat(Nonce+H(BeaconS), and the Nonce is parsed out and removed,leaving H(BeaconS), the digital fingerprint, as shown in a block 606.The sniffer will know 1) which Hash function H is used and 2) what key Kto use to generate a digital fingerprint use to authenticate the sender.Thus, the sniffer can apply the same Hash function H and key K to thedecrypted BeaconS fields/content in a received beacon (BeaconR) todetermine the validity of TokenBS. WhenH(BeaconR)=Dec(TokenBS,K)TokenBS is determined to be valid, and the answer to decision block 610(and decision block 530 in FIG. 5 a ) is YES, indicating the APtransmitting the beacon is an authorized AP, as shown in a block 614.Conversely, whenH(BeaconR)!=Dec(TokenBS,K)the answer to decision blocks 610 and 524 is NO and the logic proceedsto identify the AP transmitting the beacon as an evil twin AP in blocks612 and 518.

FIG. 7 illustrates an example of how a TokenBS comprising an HMAC may beimplemented to identify evil twin APs. In this example, an AP 702comprising an authorized AP A or Evil AP B transmits beacons (BeaconT)that are received by a sniffer 704 implemented in a standalone networkelement, an authorized AP or an authorized client. With reference tobeacon 300 b in FIG. 3 b , TokenBS 236 b is determined byTokenBS=HMAC(BeaconS,K).As shown in FIG. 7 , this corresponds to a MAC 326 b′, which isgenerated as follows. The message m for the HMAC algorithm is BeaconS,which in one embodiment is all the IEs in a beacon except thevendor-specific IE that includes the nonce and token. The message isdepicted as a message 302 a, which is provided as an input to a MACalgorithm 706 that also employs a key K₁. For HMAC, MAC algorithm 706 isan HMAC algorithm. The output of MAC algorithm 706 is a MAC 236 b′corresponding to TokenBS 236 b. Message 302 a and MAC 236 b′ areincluded in transmitted beacon BeaconT, which is broadcast to andreceived by sniffer 704, as depicted by received beacon BeaconR. Sniffer

Upon receipt of BeaconR, sniffer 704 extracts MAC 236 b′ and message 302a (i.e., BeaconS). The same MAC algorithm 706 is applied to message 320a with a key K₂, with the output of MAC algorithm 706 being a MAC 710.MAC 710 is the compared with MAC 236 b′ in a decision block 712 todetermine if they match. They will match when K₁=K₂, and will not matchotherwise. Thus, since an evil twin AP does not have K₁ or K₂ (orotherwise does not have secret key K), MAC 236 b′ and MAC 610 will notmatch.

Since the BeaconS fields/content include the timestamp field, TokenBS isa rolling token, meaning each TokenBS is different than its predecessor.This adds another level of security relative to use of the same token.Moreover, the inclusion of nonces can add a further level of security.For example, a predefined nonce pattern may be used that is known to thetrusted elements (APs, clients) in a TWE but is unknown to untrustedelements.

In addition to beacons, secure tokens may be included in othermanagement frames to validate/authenticate a communicating endpoint,such as an authorized AP or trusted client. In some embodiments theseinclude trusted probe requests and trusted probe responses. FIGS. 8 a, 8b, and 8 c show respective embodiments of trusted probe responses 800 a,800 b, and 800 c. Generally, a trusted probe response will have a formatfor a probe response defined by an applicable IEEE 802.11 MAC protocolstandard. For illustrative purposes, only selected IEs of the trustedprobe responses are shown; it will be recognized that the actual trustedprobe responses would include additional IEs that are not shown forclarity.

As shown in FIG. 8 a , trusted probe response 300 a includes a set ofsigned fields referred to as ProbeResponseS 802, followed by a token 804and (optional) requested elements 806. ProbeResponseS 802 includes theMAC header 806 and the probe response frame body 808, the latter ofwhich includes all or selected IEs 810 and a vendor-specific element812. Generally, the trusted probe response may include any required IEs,applicable optional IEs (including vendor-specific element 812) andpotentially other optional IEs. As shown in for fourth and fifth rows ofFIG. 8 a these IEs include the MAC address (BSSID) 814, a timestamp 816,beacon interval 818, capability 820, SSID 822, and one or more optionalIEs 824 (some of which may be required depending on the IEEE802.11-based PHY and other settings).

Vendor-specific IE 812 has a similar format to vendor-specific IE 222 inFIG. 2 , including a tag number, length, OUI, and type (not shown),followed by a variable length data field 826 that is used for a nonce828 and a probe response token (TokenPR) 830 a. Under trusted proberesponse 300 a,TokenPR=Enc(Cat(Nonce+H(ProbeResponseS)),K).The use of TokenPR in a trusted probe response is similar to the use ofTokenBS in a trusted beacon presented above.

Trusted probe responses 800 b and 800 c have the same format as trustedprobe response 800 a, except the TokenPR is calculated differently. Fortrusted probe response 800 b, TokenPR 830 b is defined as,TokenPR=HMAC(ProbeResponseS),K).For trusted probe response 800 c, The HMAC for TokenPR 830 c furtherincludes nonce 828 and is defined as,TokenPR=HMAC(ProbeResponseS∥Nonce),K).The operation of TokenPR 830 b and 830 c is similar to TokenBR 236 b and236 c presented above.

FIGS. 9 a and 9 b depict various messaging sequences/flows that may beperformed in connection with corresponding functions, such as validatingan AP, a client, identifying evil twin APs and rogue APs, etc. The“messages” may be in the form of beacons, probe requests, proberesponses, and other management frames or packets. In wirelessenvironments, transmissions originating from a device such as an AP ormobile device are nominally broadcast transmissions, where thetransmission itself is broadcast onto the shared wireless medium,enabling any device within the signal coverage area to receive thebroadcast transmissions. However, it is common practice to refer to atransmission that includes a specific destination (i.e., endpointdevice) as a message, packet, frame, etc., while transmissions that donot have a specific destination are referred to as broadcast signals orsimply broadcasts. Beacons are examples of such broadcasts; accordingly,in the following Figures including FIGS. 9 a and 9 b , the separatesignals that are labeled as Broadcast are actually a single broadcasttransmission rather than separate transmissions.

As shown at the top and bottom of FIGS. 9 a and 9 b , the nodes includea trusted AP 702, a neighbor AP 904, a rogue AP 906, and evil twin AP908, protected clients 910, unprotected clients 912, and a sniffer AP914. As discussed above, a sniffer may be implemented on various devicesincluding APs and clients.

Under trusted beaconing 916, trusted AP 902 broadcasts a trusted beacon918 that is depicted as being received by protected clients 910,unprotected clients 912, and a sniffer AP 914. The trusted beacons mayhave any of the trusted beacon format discussed herein, including thetrusted beacon formats shown in FIGS. 3 a, 3 b , and 3 c.

Trusted probe responses without TEPA correspond to a proberequest/response sequence where the probe request is sent to a clientdevice without a TEPA (trusted endpoint agent). Example probe requests922 and 924 are transmitted from protected clients 910 and unprotectedclients 912, respectively, with a destination of trusted AP 902. Inresponse to receiving probe request 922 and/or 924, trusted AP 902broadcasts a trusted probe response 926, which is depicted as beingreceived by protected clients 910 and unprotected clients 912, andsniffer AP 914. Generally, trusted probe response 926 may have any ofthe trusted probe response formats discussed herein, such as shown inFIGS. 8 a, 8 b , and 8 c.

Trusted probe responses with TEPA vs. untrusted probe response 928begins with a protected client transmitting a trusted probe request 930with a destination of trusted AP 902. An unprotected client 912transmits a probe request 932 comprising an untrusted probe request witha destination of trusted AP 902. In response to trusted probe request930, trusted AP 902 broadcasts a trusted probe response 934 that isreceived by protected clients 910, unprotected clients 912 and snifferAP 914.

With reference to the top of FIG. 9 b , neighbor beaconing 936 depictsneighbor AP 904 broadcasting a nominal beacon 938. In this instance,“nominal” means that this is a conventional beacon that does not includethe security information (e.g., security token) in the trusted beaconsbroadcast by trusted AP 902. Similarly, as shown by rogue beaconing 940,rogue AP 904 broadcasts a nominal beacon 942.

Evil twin beaconing 942 illustrates an example of evil twin AP 908mimicking a trusted beacon 944 broadcast from trusted AP 902. Trustedbeacon 944 is then “twinned” by evil twin AP 908 and broadcast astwinned beacon 946.

FIG. 10 shows a diagram 1000 illustrating operations for generating andbroadcasting a secure beacon, according to one embodiment. The softwarecomponents include an operating system (OS) 1002, a driver 1004, and atrusted packet library 1006. Generally, the software components willcomprise instructions such as software or firmware modules that areexecuted on a processor.

The beaconing process begins with a timer event 1010 generated by aclock 1008. The frequency of the timer events will be a function of thebeacon interval. In response to timer event 1010 an initial beacon frameis built by driver 1004 in a block 1012. The initial beacon frameincludes a timestamp 208 generated from clock 1008, and a placeholderfor the vendor-specific IE used to store the nonce and the TokenBS. Thetag, length, OUI, and type fields for the vendor-specific IE are alsopre-populated. The next set of operations is performed by trusted packetlibrary 1006, which inserts a nonce in the beacon frame in a block 1014and generates the token (i.e., TokenBS) using the BeaconS fields in ablock 1016. The generated token is then inserted into the TokenBS fieldin a block 1018, followed by the beacon being transmitted by driver 1004in an end block 1020. The scheme used to generate the token in block1016 can be any of the schemes illustrated in FIGS. 3 a, 3 b , and 3 c.

FIG. 11 shows a diagram 1100 illustrating operations for building andsending a trusted probe request, according to one embodiment. Theprocess begins with the OS initiating a trusted probe request in a startblock 1102. In a block 1104 the initial trusted probe request frame isbuilt, which includes a placeholder for the vendor-specific IE used tostore the nonce and the TokenS. The tag, length, OUI, and type fieldsfor the vendor-specific IE are also pre-populated. Trusted packetlibrary 1006 then inserts a nonce in the probe request frame in a block1106 and generates the token using the ProbeRequestS fields in a block1108. The generated token is then inserted into the TokenS field in ablock 1110, followed by the trusted probe request frame beingtransmitted by driver 1004 in an end block 1112.

FIG. 12 shows a diagram 1200 illustrating operations for building andsending a trusted probe response, according to one embodiment. Theprocess begins with a trusted probe request being received, as depictedby a start block 1202. The trusted probe request is validated in a block1204. Validation of the trusted probe request may be performed in asimilar manner to validation of the trusted beacons presented above. Asdepicted by a decision block 1206, when the trusted probe request isvalid, the logic proceeds to a block 1208 in which the initial trustedprobe response is built, which includes a timestamp 208 generate byclock 1008 and a placeholder for the vendor-specific IE used to storethe nonce and the TokenPR, with the tag, length, OUI, and type fieldsfor the vendor-specific IE pre-populated.

The logic next proceeds to trusted packet library 1006 inserting thenonce in a block 1210 and generating TokenPR using the ProbeRequestSfields in a block 1212. TokenPR is then inserted into the TokenS fieldin a block 1214 followed by transmission of the trusted probe responseby driver 1004 in an end block 1216. Returning to decision block 1206,if the probe request is determined to be invalid, the answer to decisionblock 1206 is NO and the logic proceeds to skip building andtransmitting of the trusted probe response. Depending on thecircumstances, an invalid probe request may be ignored or otherwise aremediation action may be performed.

FIG. 13 shows a message flow diagram 1300 associated with securityprovisioning (i.e., provisioning of group secret keys, protected SSIDlists, EPA certs, etc., such as shown in FIG. 1 a and discussed above).In addition to the devices shown in the previous Figures, message flowdiagram 1300 further includes a cloud 1302 and a security appliance1304. Cloud 1302 represents a cloud-hosted service or set of services,that may be implemented via a Web service, microservice, Software as aService (SaaS), etc. In one embodiment a Web service or microservice isimplemented using an REST API and JSON, although this is merelyexemplary as other types of Web-based service architectures may be used.Security appliance 1304 is representative of any type of securityappliance or the like, such as UTM firewall 130 in FIGS. 1 and 1 a.

As depicted by automatic network cloud mapping 1306, devices that areconfigured to implement the security measures herein may automaticallyobtain network cloud mapping information to enable the devices tocommunicate with cloud 1302, as collectively illustrated bycommunications 1308. The devices include security appliance 1304,trusted AP 902, protected clients 910 and sniffer AP 914.

Under cloud provisioning 1310, the cloud-hosted service provisionssecurity data comprising appropriate sets of data, keys, lists, certs,etc. to security appliance 1304, trusted AP 902, protected clients 910and sniffer AP 914, as depicted by respective messages 1312, 1314, 1316,and 1318. Generally, each of security appliance 1304, trusted AP 902,and sniffer AP 914 will have a wired connection to cloud 1302.Meanwhile, protected clients, which are typically wireless clientdevices, will connect to cloud 1302 over a wireless interface.

As discussed above with reference to FIG. 1 a , an aspect ofprovisioning is performed by UMT firewall 130, which corresponds tosecurity appliance 1304 in FIG. 13 . As depicted by security applianceprovisioning 1320, security appliance 1304 provisions securitydata/configuration information comprising sets of data, keys, certs,lists, etc. to trusted AP 902, protected clients 910, and sniffer 914,as depicted by messages 1322, 1324, and 1326. For example, trusted AP902 corresponds to authorized APs 102, 104, and 106 in FIG. 1 a , whereUTM firewall 130 pushes down configuration data 164 to agents 136. Whenthe functionality of a sniffer AP 914 is implemented in a trusted (e.g.,authorized) AP, separate provisioning of security data will not beneeded.

FIG. 14 shows a message flow diagram 1400 related to a trustedassociation sequence originating from a trusted probe request 1402.Under a trusted association sequence, a protected client 910 obtains anassociation with a trusted AP. The process begins with a protectedclient 910 sending a trusted probe request 1404 to trusted AP. Asdiscussed above, the trusted probe request includes a token that isvalidated by trusted AP 902, as depicted by validate token 1406. If thetoken is invalid, the sequence stops, as depicted by a decision block1408. Otherwise (when the token is valid), AP 902 sends a trusted proberesponse 1410 to protected client 902, which validates the token (1412).If the token is invalid, the sequence stops, as depicted by a decisionblock 1414.

Under the embodiment illustrated in FIG. 14 , a similar security tokenmeasure is implemented for each of the remaining messages in thesequence, which include an authentication open seq:1 message 1416, anauthentication open seq:2 message 1422, an authentication request 1428,and an association response 1434. As depicted by validate token 1418,1424, 1430, and 1436, the token in these messages is validated at therecipient (trusted AP 902 or protected client 910 as applicable), and asdepicted by decision block 1420, 1426, 1432 and 1438 the sequence isstopped when a token is determined to be invalid (which may also includea missing token). Generally, the format of open seq:1 message 1416,authentication open seq:2 message 1422, authentication request 1428, andassociation response 1434 may have the format for a management frameshown in FIG. 2 a , where the token is embedded in a vendor-specific IE222. The use of a nonce is optional in these messages.

Under variations of message flows for establishing a trusted associationbetween a protected client and a trusted AP, only a portion of themessages contain security tokens. For example, under one embodimenttrusted probe request 1404 and trusted probe response 1410 includesecurity tokens, while open seq:1 message 1416, authentication openseq:2 message 1422, authentication request 1428, and associationresponse 1434 do not. The use of security tokens for these messages addsan extra layer of protection but are optional under some embodiments. Asother options, security tokens may be included for open seq:1 message1416 and authentication open seq:2 message 1422 and not included forauthentication request 1428 and association response 1434, or securitytokens may be included for authentication request 1428 and associationresponse 1434, while be omitted for open seq:1 message 1416, andauthentication open seq:2 message 1422.

FIG. 15 shows a message flow diagram 1500 relating to trusteddeauthentication 1502. Trusted deauthentication may be used todeauthenticate clients that have connected evil twin APs by having atrusted AP 902 broadcast trusted deauthentication messages 1504 and 1506to protected clients 910 and unprotected clients 912. The broadcasttrusted deauthentication messages will cause protected clients 910 andunprotected clients 912 to disconnect with an evil twin AP.

In generally, the authentication schemes described herein may beextended to any type of 802.11 frame that includes a vendor-specific IE.In addition, a similar approach may be used for a vendor specific actionframe, wherein content in the frame header could be used as the hasheddata, and the encrypted content, MAC, or HMAC could be stored in thevendor specific content field.

Exemplary Trusted/Authorized AP

FIG. 15 depicts a block diagram illustrating example components ofrepresentative trusted or authorized AP, according to one embodiments.Various components, functional blocks and interfaces are shown withreference to Figure, however, the AP device does not require all of thecomponents, functional blocks, and interfaces for performing thefunctionality described herein. It is appreciated that, in manyembodiments, various components are not included and/or necessary foroperation of an AP device. In addition, the AP device can includeadditional components that are not shown for brevity.

As shown in FIG. 16 , trusted AP 1600 includes a processor 1602 that iscoupled a single or multi-PHY radio chip 1604 and an optional single ormulti-PHY radio chip 1606. A multi-PHY radio chip is capable ofsupporting multiple IEEE 802.11-based PHY protocols. In the illustratedembodiment, processor 1602 includes a CPU (central processor unit) 1608including one or more cores 1610 coupled to an interconnect 1612.Interconnect 1612, which is representative of one or more levels ofinterconnects (e.g., in an interconnect hierarchy) is further connectedto a memory interface 1614 and Input/Output (I/O) interfaces 1616, 1618,1620, and 1622. Memory interface 1614 enables the processor to accessmemory 1624, which generally may be a form of volatile memory, such asDynamic Random Access Memory (DRAM), or a non-volatile memory, such as,but not limited to flash memory. Memory 1624 may further be implementedas a combination of volatile and non-volatile memory, such as Intel® 3DXpoint™ memory.

Single or multi-PHY radio chip 1604 includes an I/O interface 1616, acontrol logic block 1628, a single or multimode MAC block 1630, a singleor multimode PHY block 1632, transmitter circuitry 1634, and receivercircuitry 1636. Single or multi-PHY radio chip 1604 is further coupledto an antenna 1638, collectively forming a first radio subsystem.Antenna 1638 is representative of a single or multiple antenna, such asimplemented in a MIMO (multiple input, multiple output) radio interface.

Similarly, optional single or multi-PHY radio chip 1606 includes an I/Ointerface 1640, a control logic block 1642, a single or multimode MACblock 1644, a single or multimode PHY block 1646, transmitter circuitry1648, and receiver circuitry 1650. Single or multi-PHY radio chip 1606is further coupled to an antenna 1652, collectively forming a secondradio subsystem. As before, antenna 1652 is representative of a singleor multiple antenna.

A storage device 1654 representing one or more storage devices on whichfirmware or software is stored, is coupled to processor 1602 via I/Ointerface 1620. For example, exemplary stored devices including flashmemory, solid state drives (SSDs), magnetic media drives, or variousother types of storage devices suitable for storing firmware and/orsoftware.

A network interface 1656 is connected to processor 1602 via I/Ointerface 1622, enabling the wireless device 1600 to access a wirednetwork 1658 using a wire connection. For example, network interface maybe an Ethernet interface or Ethernet Network Interface Controller (NIC),an InfiniBand Host Controller Adaptor (HCA), or a network interface inaccordance with various other types of wired network standards.

Trusted AP 1600 further is depicted as including an optional directmemory access (DMA) block 1660. DMA block 1660 is representative of DMAfunctionality that may be provided by wireless device 1600; as will beunderstood by one skilled in the processor art, DMA functionality isactually implemented via multiple components rather than a single logicor functional block. For example, in one embodiment, at least a portionof the I/O interfaces are PCIe (Peripheral Component InterconnectExpress) interfaces, which, along with other circuitry not shown,including a PCIe root complex that would be coupled to interconnect1612, enable data to be transferred between a component external toprocessor 1602 (such as one or both single or multi-PHY radio chips 1604and 1606) and memory 1624 without use of CPU 1608.

Various functionality for the wireless devices described herein may beimplemented using “control logic,” which is collectively used to referto logic that may be used to implement corresponding control andcommunication operations. The control logic may be implemented in one ormore components, or in a distributed manner under which portions of thecontrol logic are implemented in different components. For this reason,the various blocks depicting “control logic” are shown in dashedoutline, indicating they are optional.

One mechanisms for implementing all or a portion of the control logic isvia execution of corresponding firmware or software that is stored instorage device 1654, loaded into memory 1624, and executed on one ormore or processor cores 1610, as depicted by control logic 1662.Optionally, all or a portion of the control logic for controlling thePHY and MAC of a given radio subsystem may be implemented on theassociated radio chip, such as depicted by control logic 1628 and 1642.As yet another option, separate embedded logic may be used, as depictedby an embedded processor or controller 1664 and control logic 1666. Moregenerally, the embedded logic may be implemented using one of severalwell-known approaches, such as executing firmware/software on anembedded processor or controller, using an Application SpecificIntegrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA), orthe like. Likewise, control logic 1628 and 1642 may be implemented in asimilar manner. In some embodiments, 802.11 radio functionality may beimplemented in a Software Defined Radio (SDR).

In some embodiments a dedicated sniffer radio is used for implementingthe sniffer functionality described herein. For example, in trusted AP1600, single or multi-PHY radio chip 1604 may be used for trusted AP802.11 communication, while single or multi-PHY radio chip 1606 isdedicated for sniffer operations. When a separate 802.11 radio is notused, sniffing may be interleaved with AP traffic using one or moreradios.

Exemplary Protected Client

FIG. 17 depicts a block diagram illustrating example components of arepresentative protected client comprising a mobile device 1700 in theform of a mobile (or smart) phone or tablet computer device, accordingto an embodiment. Various interfaces and modules are shown withreference to FIG. 17 ; however, the mobile device or tablet computerdoes not require all of the modules or functions for performing thefunctionality described herein. It is appreciated that, in manyembodiments, various components are not included and/or necessary foroperation of the category controller. For example, components such asGPS radios, cellular radios, and accelerometers may not be included inthe controllers to reduce costs and/or complexity. Mobile device 1700includes software and/or firmware for implemented the functionalityassociated with protected client devices described herein, including aTEPA 154.

As shown in FIGS. 1 and 1 a, protected client may also be implemented ina notebook computer or laptop. Notebook and laptop computers maygenerally include similar components to those shown for mobile device1700, sans the 3G/4G/5G modem and SIM card and SIM card interface. Thenotebook and laptop computer components will include a processor or CPUcoupled to one or more memory devices in which instructions may beloaded and executed to implement the security functionality describedfor protected clients comprising notebook and laptop computers disclosedherein. In addition to mobile devices, protected clients may includedesktop PCs and workstations and IoT devices.

In some network apparatus, such as APs and clients, the logicillustrated in the various diagrams herein may be implemented usingembedded logic, including but not limited to software and/or firmwareexecuted on an embedded processor or one or more processing elementsand/or hardware circuitry such as ASICs (application specific integratedcircuits and FPGAs (Field Programmable Gate Arrays) and/or other typesof programmable logic. As used herein including the claims, the term“logic” applies to logic and operations described and illustrated hereinthat may be implemented via execution of software or firmware on aprocessor or one or more processing elements, may be implemented inembedded hardware logic, or may be implemented using a combination ofthe two.

Although some embodiments have been described in reference to particularimplementations, other implementations are possible according to someembodiments. Additionally, the arrangement and/or order of elements orother features illustrated in the drawings and/or described herein neednot be arranged in the particular way illustrated and described. Manyother arrangements are possible according to some embodiments.

In each system shown in a figure, the elements in some cases may eachhave a same reference number or a different reference number to suggestthat the elements represented could be different and/or similar.However, an element may be flexible enough to have differentimplementations and work with some or all of the systems shown ordescribed herein. The various elements shown in the figures may be thesame or different. Which one is referred to as a first element and whichis called a second element is arbitrary.

In the description and claims, the terms “coupled” and “connected,”along with their derivatives, may be used. It should be understood thatthese terms are not intended as synonyms for each other. Rather, inparticular embodiments, “connected” may be used to indicate that two ormore elements are in direct physical or electrical contact with eachother. “Coupled” may mean that two or more elements are in directphysical or electrical contact. However, “coupled” may also mean thattwo or more elements are not in direct contact with each other, but yetstill co-operate or interact with each other. Additionally,“communicatively coupled” means that two or more elements that may ormay not be in direct contact with each other, are enabled to communicatewith each other. For example, if component A is connected to componentB, which in turn is connected to component C, component A may becommunicatively coupled to component C using component B as anintermediary component.

An embodiment is an implementation or example of the inventions.Reference in the specification to “an embodiment,” “one embodiment,”“some embodiments,” or “other embodiments” means that a particularfeature, structure, or characteristic described in connection with theembodiments is included in at least some embodiments, but notnecessarily all embodiments, of the inventions. The various appearances“an embodiment,” “one embodiment,” or “some embodiments” are notnecessarily all referring to the same embodiments.

Not all components, features, structures, characteristics, etc.described and illustrated herein need be included in a particularembodiment or embodiments. If the specification states a component,feature, structure, or characteristic “may”, “might”, “can” or “could”be included, for example, that particular component, feature, structure,or characteristic is not required to be included. If the specificationor claim refers to “a” or “an” element, that does not mean there is onlyone of the element. If the specification or claims refer to “anadditional” element, that does not preclude there being more than one ofthe additional element.

An algorithm is here, and generally, considered to be a self-consistentsequence of acts or operations leading to a desired result. Theseinclude physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It has proven convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers or the like.It should be understood, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities.

As discussed above, various aspects of the embodiments herein may befacilitated by corresponding software and/or firmware components andapplications, such as software and/or firmware executed by an embeddedprocessor or the like. Thus, embodiments of this invention may be usedas or to support a software program, software modules, firmware, and/ordistributed software executed upon some form of processor, processingcore or embedded logic a virtual machine running on a processor or coreor otherwise implemented or realized upon or within a non-transitorycomputer-readable or machine-readable storage medium. A non-transitorycomputer-readable or machine-readable storage medium includes anymechanism for storing or transmitting information in a form readable bya machine (e.g., a computer). For example, a non-transitorycomputer-readable or machine-readable storage medium includes anymechanism that provides (i.e., stores and/or transmits) information in aform accessible by a computer or computing machine (e.g., computingdevice, electronic system, etc.), such as recordable/non-recordablemedia (e.g., read only memory (ROM), random access memory (RAM),magnetic disk storage media, optical storage media, flash memorydevices, etc.). The content may be directly executable (“object” or“executable” form), source code, or difference code (“delta” or “patch”code). A non-transitory computer-readable or machine-readable storagemedium may also include a storage or database from which content can bedownloaded. The non-transitory computer-readable or machine-readablestorage medium may also include a device or product having contentstored thereon at a time of sale or delivery. Thus, delivering a devicewith stored content, or offering content for download over acommunication medium may be understood as providing an article ofmanufacture comprising a non-transitory computer-readable ormachine-readable storage medium with such content described herein.

The operations and functions performed by various components describedherein may be implemented by software running on a processing element,via embedded hardware or the like, or any combination of hardware andsoftware. Such components may be implemented as software modules,hardware modules, special-purpose hardware (e.g., application specifichardware, ASICs, DSPs, etc.), embedded controllers, hardwired circuitry,hardware logic, etc. Software content (e.g., data, instructions,configuration information, etc.) may be provided via an article ofmanufacture including non-transitory computer-readable ormachine-readable storage medium, which provides content that representsinstructions that can be executed. The content may result in a computerperforming various functions/operations described herein.

As used herein, a list of items joined by the term “at least one of” canmean any combination of the listed terms. For example, the phrase “atleast one of A, B or C” can mean A; B; C; A and B; A and C; B and C; orA, B and C.

The above description of illustrated embodiments of the invention,including what is described in the Abstract, is not intended to beexhaustive or to limit the invention to the precise forms disclosed.While specific embodiments of, and examples for, the invention aredescribed herein for illustrative purposes, various equivalentmodifications are possible within the scope of the invention, as thoseskilled in the relevant art will recognize.

These modifications can be made to the invention in light of the abovedetailed description. The terms used in the following claims should notbe construed to limit the invention to the specific embodimentsdisclosed in the specification and the drawings. Rather, the scope ofthe invention is to be determined entirely by the following claims,which are to be construed in accordance with established doctrines ofclaim interpretation.

What is claimed is:
 1. A method for detecting an evil twin access point(AP), comprising: broadcasting, from a first IEEE 802.11-based APcomprising a trusted AP having a coverage area in which a second APcomprising an IEEE 802.11-based AP is located, a first beacon comprisinga trusted beacon including a service set identifier (SSID) for thetrusted AP and containing a security token generated with at least onecryptographic operation employing a secret key and contained in a datafield of a vendor-specific information element (IE) in the trustedbeacon; receiving a second beacon including the SSID broadcast by thesecond AP; and examining content of multiple IEs in the second beacon todetect the second beacon was broadcast by an evil twin AP.
 2. The methodof claim 1, wherein the evil twin AP is detected by determining thesecond beacon does not include a security token in the data field of avendor-specific IE.
 3. The method of claim 1, wherein the first beaconincludes a timestamp generated using a clock on the trusted AP and thesecond beacon is a copy of the first beacon including the sametimestamp, and wherein the second beacon is detected to be broadcast byan evil twin AP by determining a difference between a time the secondbeacon is received and the timestamp in the second beacon exceeds athreshold, wherein the time the second beacon is received is detectedusing a clock in a sniffer AP that is synchronized with the clock in thetrusted AP.
 4. The method of claim 1, wherein the first beacon comprisesa header followed by a beacon frame body including a plurality of IEsfollowed by the vendor-specific IE, and wherein the secure token isgenerated, at least in part by: performing a hash over all datacontained in the header and the plurality of IEs before thevendor-specific IE or data contained in at least a portion of the headerand selected IEs in the plurality of IEs before the vendor-specific IEto generate a digest; and encrypting data including at least the digestusing the secret key.
 5. The method of claim 4, wherein the data fieldof the vendor-specific IE further comprises a nonce, and wherein thedata that is encrypted with the secret key is composed of the nonceconcatenated with the digest.
 6. An access point (AP), comprising: atleast one IEEE 802.11 radio configured to support at least one PHY(Physical layer) and MAC (Media Access Channel layer) defined by an IEEE802.11 PHY standard; a processor, operatively coupled to the at leastone IEEE 802.11 radio; memory, coupled to the processor; and logicconfigured to, generate a security token using at least onecryptographic operation employing a secret key; broadcast a first beaconcomprising a first trusted beacon including a service set identifier(SSID) for the AP and containing the security token in a data field of avendor-specific information element (IE) in the first beacon; receive asecond beacon including the SSID broadcast by a second AP; and examinecontent of multiple IEs in the second beacon to detect the second beaconwas broadcast by an evil twin AP.
 7. The AP of claim 6, wherein the eviltwin AP is detected by determining the second beacon does not include asecurity token in the data field of a vendor-specific IE.
 8. The AP ofclaim 6, wherein the first beacon comprises a header followed by abeacon frame body including a plurality of IEs followed by thevendor-specific IE, and wherein the secure token is generated by:employing a hash or cryptographic hash over all data contained in theheader and the plurality of IEs before the vendor-specific IE or datacontained in at least a portion of the header and selected IEs in theplurality of IEs before the vendor-specific IE to create a digest; andencrypting data including at least the digest using the secret key. 9.The AP of claim 8, wherein the data field of the vendor-specific IEfurther comprises a nonce, and wherein the data that is encrypted withthe secret key is composed of the nonce concatenated with the digest.10. The AP of claim 6, wherein the first beacon comprises a headerfollowed by a beacon frame body including a plurality of IEs followed bythe vendor-specific IE, and wherein the secure token is generated byemploying a MAC (message authentication code) or an HMAC (hash-basedmessage authentication code) algorithm employing the secret key andusing a message comprising all data contained in the header and theplurality of IEs before the vendor-specific IE or data contained in atleast a portion of the header and selected IEs in the plurality of IEsbefore the vendor-specific IE.
 11. A non-transitory machine-readablemedium having instructions stored thereon comprising one or moresoftware modules that are configured to be executed on a processor in afirst IEEE 802.11 access point (AP) to enable the first IEEE 802.11 APto: generate a security token using at least one cryptographic operationemploying a secret key; generate a beacon frame including a service setidentifier (SSID) for the first IEEE 802.11 AP and including thesecurity token, the beacon frame to be broadcast as a first beaconcomprising a first trusted beacon by the first IEEE 802.11 AP; andexamine content in multiple information elements (IEs) in a secondbeacon that is broadcast by a second IEEE 802.11 AP and received by thefirst IEEE 802.11 AP to detect the second beacon was broadcast by anevil twin AP.
 12. The non-transitory machine-readable medium of claim11, wherein the security token is contained in a data field of avendor-specific IE in the first beacon, and wherein the evil twin AP isdetected by determining the second beacon does not include a securitytoken in the data field of a vendor-specific IE in the second beacon.13. The non-transitory machine-readable medium of claim 11, wherein thefirst beacon comprises a header followed by a beacon frame bodyincluding a plurality of IEs followed by a vendor-specific IE, andwherein the secure token is generated by employing a MAC (messageauthentication code) or an HMAC (hash-based message authentication code)algorithm employing the secret key and using a message comprising alldata contained in the header and the plurality of IEs before thevendor-specific IE or data contained in at least a portion of the headerand selected IEs in the plurality of IEs before the vendor-specific IE.14. The non-transitory machine-readable medium of claim 11, wherein thefirst beacon comprises a header followed by a beacon frame bodyincluding a plurality of IEs followed by the vendor-specific IE, andwherein the secure token is generated by: employing a hash orcryptographic hash over all data contained in the header and theplurality of IEs before the vendor-specific IE or data contained in atleast a portion of the header and selected IEs in the plurality of IEsbefore the vendor-specific IE to create a digest; and encrypting dataincluding at least the digest using the secret key.
 15. Thenon-transitory machine-readable medium of claim 14, wherein the datafield of the vendor-specific IE further comprises a nonce, and whereinthe data that is encrypted with the secret key is composed of the nonceconcatenated with the digest.